A characteristic of so-called intelligent networks (see the Q.1200 series of ITU-T Recommendations) is a distributed architecture (see, for example Q.1214) in which a so-called service switching function (SSF) is “controlled” by a so-called service control function (SCF). The two functions are normally (but not necessarily) provided in different physical nodes (the so-called service control point, SCP and the service switching point, SSP). The so-called INAP (Intelligent Network Application Part) protocol, which is based on TC (Transaction Capabilities, see Q.77×), SCCP (Q.71×) MTP (Q.70×) is used for communication in this case.
Applications presently exist in which an SCP starts processing of a transaction, but completes the processing in another SCP. This is described below.
In conventional applications, the standards do not provide any solution for a continuation of transaction processing. Rather, a so-called transfer is feasible, in which the message opening the transaction is passed on to the next SCP after initial treatment. In this case, the logical sender of the message is not changed. Hence, for the next SCP, it appears as if the message had arrived directly from an SSP. The SCP can then respond directly to the SSP, so that any further messages for the transaction can be interchanged directly between the SSP and the new SCP.
However, if it is necessary for the first SCP to interchange further messages with the SSP, then the transfer is no longer possible. One situation in which a further message interchange is necessary is that where the first message did not at that stage contain sufficient address information (for example dialed digits) in order to define the second SCP responsible for the further processing.
Since, with the first return message which it receives for the transaction, the SSP stores the address of the message sender, including the identification used by the sender for that transaction, and uses the information for all future messages to be transmitted for this transaction, the SSP will send all further messages to the first SCP even if the latter has in the meantime transferred the processing to the second SCP.
Thus, in this case, the first SCP is still included in the communication between the SSP and the second SCP. This is because, instead of a transfer, the first SCP must open its own transaction with the second SCP and must remain as a communication distributor in the dialog between the SSP and the second SCP. For this purpose, the first SCP must process the messages to be interchanged between the second SCP and the SSP such that it replaces the addresses and the transaction identification of the second and first SCPs for messages which are sent from the second SCP to the first SCP, by those for the transaction between the first SCP and the SSP, and passes on the amended messages to the SSP.
Conversely, messages from the SSP are processed in the first SCP such that the addresses and transaction identifications of the SSP and first SCP are replaced by those applicable to the transaction between the first SCP and the second SCP, and the amended messages are passed on to the second SCP. This is referred to as an application relay, which is carried out by the first SCP.
As can be seen immediately, this solution has the disadvantage that, even though it does not have to carry out any additional tasks for the transaction or transactions, other than the relaying process, the first SCP is still included in the communication process and, except for the TC protocol level, has to analyze and amend the messages. This wastes not only time but also processor and memory resources.